在軟體測試的實踐中，「ST 主導與 ET 輔助」（簡稱為 ST 主導方式）是一種偏向於傳統腳本測試的混合實踐模式。這種方式旨在確保測試嚴謹性的同時，透過探索式測試來增加發現未知缺陷的機會。以下是針對該方式的兩層核心定義：

• 第一層：ST 主導（腳本測試主導）
  測試人員在整體的測試過程中，需要撰寫詳盡的測試案例，並嚴格依據這些測試案例來執行測試活動。這保證了測試內容的詳細程度、可追蹤性以及經驗的傳承性。

• 第二層：ET 輔助（探索式測試輔助）
  在執行那些已經產生的測試案例時，測試人員並非機械式地操作，而是同時實施探索式測試。測試員會根據被測產品的實際輸出反應，即興設計並執行更多原本不在腳本內的測試案例。

這種實踐方式既能透過詳盡腳本保證產品品質的底線，也能透過探索行為提高測試的多樣性。在執行例行腳本時加入探索思維，能讓日趨僵化的腳本測試變得更有變化與活力。此方式沒有太多硬性要求，實踐者可以修改現有腳本測試流程中的某一環節來進行客製化實施。

實施「ST 主導與 ET 輔助」方式的探索式測試，主要需設法滿足以下基本條件：

(1) 產品的主要功能趨於穩定：該實踐方式適用於產品功能已趨於穩定的階段，且專案通常已經通過了第二輪測試以及安全測試。

(2) 探索式測試計劃獲得支持：關於探索式測試的計劃與安排，需要得到測試經理以及專案經理的認可與支持。

(3) 預期回歸測試的缺陷發現率較低：根據過往的經驗或數據顯示，在進入第三輪回歸測試時，預期能發現的缺陷機率已經相對較低。

(4) 具備風格統一且清晰易懂的測試案例：為了方便測試團隊成員之間交叉執行測試，團隊應使用統一風格來編寫清晰且易於理解的測試案例。

這套實施條件的設計初衷是為了在確保產品質量底線的同時，利用探索式測試來提高測試的多樣性。

在測試執行過程中，測試策略並非一成不變，而是必須根據產品的「成熟度」進行動態調整。知名測試專家 Cem Kaner 建議，隨著專案從初期走向發布，測試人員應該靈活切換不同的角色與策略，而不是始終抱著同一套測試案例。

以下根據產品開發的四個階段，說明對應的測試策略：

(1) 專案初期：同情地測試
在開發剛開始的階段，測試人員對產品的了解通常還不夠深入。此時不必進行過於生硬或複雜的測試，因為產品還很脆弱，即便只是進行簡單的主流程操作，也極大機率會發現問題。這時的重點是「了解產品」，而不是急著擊垮它。

(2) 專案中期：積極地測試
隨著產品逐漸成形，主要功能已經實現，簡單的基礎測試已失去意義。此時開發人員對產品更有信心，測試人員應將重點轉向錯誤修復與深度挖掘。實施更嚴格、更複雜的測試組合，層層深入產品的各個角落。這通常是缺陷被大量發現的高峰期。

(3) 專案末期：多樣地測試
當產品接近成熟，要找出剩餘的錯誤會變得更加困難。此階段需要極大的「創造力」。測試團隊應綜合運用多種手段，例如交叉測試、自動化測試、缺陷大掃除或用戶測試。充分發揮想像力，利用任何有助於發現隱藏問題的方法，讓缺陷發現率維持在高峰。

(4) 專案發佈前：嚴謹地測試
在產品即將發布前的最後關頭，任何細小的變動都可能引發嚴重的災難。測試人員必須採取一絲不苟的態度，檢查每一個代碼變更。確保最後一刻的修改不會導致嚴重的「回歸缺陷」。此時甚至可以利用「結對測試」來為品質多增加一層保障。

根據上圖中的內容，我們可以將探索性測試介入的時機與重點歸納為以下幾個關鍵點：

(1) 開發前期：建立基礎認知與風險評估
在需求與設計階段，探索性測試不只是「測軟體」，更多是「測邏輯」與「了解背景」。

A. 探索前版功能：在新功能開發前，透過探索舊版本的行為，確保團隊對現有業務邏輯有共識，並識別出可能的影響範圍（Impact Analysis）。

B. 了解前版設計：深入研究先前的系統架構與設計模式，這有助於測試者預判新變更可能在哪裡引發「副作用」。

(2) 進入測試階段的門檻檢核
在正式進入功能測試前，確保環境與版本的穩定。

C. 確認版本可測： 這類似於「冒煙測試」（Smoke Testing）。透過探索性操作快速確認基本功能是否運作，避免浪費時間在一個連路徑都不通的不穩定版本上。

(3) 功能測試期間：深度與廣度的挖掘
這是探索性測試最活躍的階段，特別是在「第一輪」與「第二輪」功能測試中。

D. 交換測試： 由不同的測試人員交換負責模組，利用「不同的視角」來發現原負責人可能產生的盲點。

E. 探索特定 Bug： 當自動化測試或一般測試案例發現異常時，透過 ET 深入追蹤該 Bug 的觸發邊界、複現路徑及其對周邊功能的連鎖反應。

F. 第三輪測試： 在經過前兩輪的洗禮後，針對較脆弱或邏輯複雜的區域進行最後的掃蕩，捕捉那些隱藏在邊緣案例（Edge Cases）中的問題。

(4) 後期加固與自動化整合
在測試後期（Beta/Stage），探索性測試用於確保修復品質並回饋給自動化腳本。

G. Bug fix 的補強： 針對已修復的 Bug 進行探索，確保「修好 A 沒壞 B」（回歸測試），並嘗試用不同的操作順序再次挑戰該 Bug 的穩定性。

H. 補強自動化： 探索性測試中發現的高價值路徑、常見錯誤操作，應轉化為自動化測試案例，以減輕未來手動測試的負擔。

在執行現場，探索性測試最怕陷入「漫無目的」或「資訊孤島」。以下是一些執行守則：

(1) 拒絕悶頭苦幹，建立「即時回饋循環」
探索性測試員有時會因為不熟悉需求細節而卡關。若嘗試多次仍無法推動流程，請立刻找專案其他成員溝通。有時開發人員的一句提示，就能解開測試路徑的死胡同。敢於提問、快速解決問題，才是高效測試的表現。

(2) 擺脫測試案例的緊箍咒
ET 的靈魂在於「人的主動性」，而非機械式地勾選檢查清單。測試人員應依照自己的邏輯與直覺來設計測項，而非被動執行既有的用例。當思緒枯竭時，可以參考測試案例的「標題」來發散思維，但不要被舊思維限制。